Using Tracing and Dynamic Slicing to Tune Compilers

Performance tuning improves a compiler s performance by detecting errors and missed opportunities in its analysis optimization and code generation stages Normally a com piler s author tunes it by examining the generated code to nd suboptimal code sequences This paper describes a collection of tools called compiler auditors that assist a compiler writer by partially mechanizing the process of nding suboptimal code sequences Although these code sequences do not always exhibit compiler bugs they frequently illustrate problems in a compiler Experiments show that auditors e ectively nd suboptimal code even in a high quality commercial compiler After writing a high quality compiler its authors improve it with the time consuming and te dious process of examining generated assembly code to nd ine cient code sequences that could run faster or consume less space These sequences direct a compiler writer s attention to places in the compiler at which improved analysis optimization or code generation would result in bet ter code Typically a compiler writer nds this suboptimal code by reading assembly language listings of compiled code see for example Briggs Performance tuning of this sort is un avoidable for two reasons Compilers are large and complex programs that will contain bugs that a ect the performance but not correctness of generated code More fundamentally compiler writing is an art in which the insight necessary for e ective heuristics arise from identifying past mistakes This paper describes a technique for partially automating the tedious process of detecting suboptimal code In this approach specialized programs called compiler auditors examine a complete instruction and data trace of a compiled test program and dynamically detect se quences of executed instructions that could have been compiled better The auditor reports these sequences to the compiler writer who still must examine the designated portions of the compiled program to determine if the code can be improved and how to modify the compiler The advantage of compiler auditing is that auditors direct a compiler writer s attention to per formance problems faster than a manual search and more reliably than intuition Information and feedback from tools of this sort can reduce the time and e ort required to produce a mature University of Wisconsin Computer Sciences Department Technical Report This work was supported in part by the National Science Foundation under grant CCR and by the Wisconsin Alumni Research Foundation high quality compiler that generates e cient as well as correct code The approach is simple and requires a small investment of time and e ort A compiled code sequence is suboptimal if a shorter or faster sequence of instructions produces the same e ect on the program s state Suboptimal code arises from three sources Defects in a compiler which can either be errors of omission in which a compiler writer did not consider a case or errors of commission in which the compiler is actually incorrect i e has a bug For example a code generator may not produce a decrement and branch instruction because it is not included in the code generator tables or because an earlier stage improperly normalized a loop s bounds Conservative program analysis which sacri ces precision in particular cases for correctness in general In this case a compiler does not perform an optimization because it cannot guarantee a necessary prerequisite Frequently program analysis is improved by identifying special cases that can be precisely analyzed Heuristic algorithms which do not always produce good results A good example is graph coloring register allocation which addresses an NP complete problem whose precise e cient solution is not possible The primary way to understand and improve a heuristic s performance is to examine its behavior on real programs These compiler problems are manifest as performance not correctness de ciencies and will not be detected by a typical user or inattentive compiler writer The compiled code computes the correct output albeit more slowly than necessary Isolating and correcting these problems is costly The decision whether to x a problem depends on the performance cost of suboptimal code and the frequency with which it is produced Compiler writers typically guess at the latter parameter Another application for a compiler auditor is to examine a large body of code to determine how often a suboptimal code sequence arises Suboptimal code can be detected either by statically examining generated instructions or by dynamically examining a program trace The rst alternative is the basis of many compilers which operate by generating simple code and then improve it by identifying and replacing suboptimal code e g Compiler writers typically tune their compilers by applying the same process in a more intuitive and ad hoc way on the compiled code Manually performing this process is di cult and error prone particularly for large procedures with complex control ow because a human must mentally compute large program traces and slices In addition a compiler writer may easily miss an optimization twice rst when writing a compiler and then when tuning it Finally when applied to a compiler s assembly output this approach misses ine ciencies introduced at lower levels such as the assembler and linker As an example a group at CSRD examined the Cedar parallelizer to determine why it could not restructure the Perfect Club benchmarks This process was expensive and required several person months per benchmark Another alternative is to examine the stream of instructions when a program executes An auditor can either use this stream to directly identify ine cient sequences or it can construct a dynamic program slice to nd redundant computations This process has the advantages that it is cheaply and easily mechanizable does not require sophisticated static analysis and concentrates on frequently executed traces in a program On the other hand this approach changes the de nition of suboptimal Code executed in a sequence or slice is suboptimal for a particular execution On other paths through the program the code sequence may be optimal Consequently a code sequences does not demonstrate a compiler bug rather it illustrates a test−prog.c test−prog qpt (tracing program) test−prog.QTrace (trace file) xxx−auditor.c (compiler auditor) test−prog−regen.c (trace−regenerator) Auditor